Patterns and an Antiidiom for Aspect Oriented Programming

There are many different options when using AOP tools or languages to solve similar problems. Modern AOP languages offer new features and design ideas, through the combination of object and aspect oriented features. Patterns are therefore required to guide AOP developers and architects around the common pitfalls and unleash the power of Aspect Oriented Programming. This paper describes three patterns and one common antiidiom. The first pattern PROCEED OBJECT deals with the problem how to delegate the execution of an around advice. The second pattern EAGER POINTCUT DECISION deals with the problem, how to avoid or reduce the performance hits of advices, which may be enabled or disabled at runtime. The third pattern notbelow describes a pattern, which handles the forces which the antiidioms NOTWITHIN should often resolve. Introduction Objects have been quite successful in the past to modularize and organize the implementation of the core requirements. Object Oriented technology created new architectures and solved problems. It proved also quite successful in creating new architectures. However due to the increasing complexity of modern programs non business concerns got more and more important. Typical examples include transaction handling, persistency, tracing, logging, and contract checking, etc. Object technology failed to handle these additional concerns in a modular way. Aspect oriented programming (AOP) proved quite successful in modularizing these concerns [5][6]. However AOP is quite a new programming paradigm, which has not jet entered mainstream software development. This paper contains a short introduction to the features of AspectJ in order to support the reader, who may not jet be familiar with AOP. Most AOP based applications are currently built on top of an existing Object Oriented -code base. Sometimes an existing Object Oriented or component framework is enhanced by some pluggable or optional aspects, and sometimes they are even evolved to an Aspect Oriented Framework. This paper describes three patterns and one idiom, which provided quite useful in these scenarios. • The PROCEED OBJECT pattern is often used to convert a proceed call in an advice to an object. This object can participate in “classical” object oriented approaches, idioms and patterns like the famous command pattern[1]. • The EAGER POINTCUT DECISION pattern can be used to eliminate potential performance bottlenecks, typically caused by optional advices, which might be turned on or off, often even after the weaving took place. (e.g. for a configurable logging and tracing framework),. • The NOTWITHIN antiidiom describes an often used and suggested idiom to ensure that a very unspecific advice is not applied in infinite recursion. • And the third pattern NOTBELOW describes, how to ensure that an advice is executed only once in a call stack, even if aspect inheritance is used to decide where an aspect should be applicable. This pattern provides a usable solution for the antiidiom NOTWITHIN. Although all the samples and code fragments are written in AspectJ and the names are influenced deeply by AspectJ terms, the patterns and idioms are useful outside AspectJ. All patterns are applicable to other AOP Frameworks (e.g. aspektwerks[10], JBoss-AOP[11], Nanning[12]) and languages like Sally ([13]). The PROCEED OBJECT pattern is even quite useful in plain old java programs and architectures, which rely heavily on dynamic interceptors, a feature in the J2SE since its Version 1.3 [18]. The antiidiom itself can be applied in all AOP Frameworks and languages, which offer a capability to advice its own code. However I have seen this antiidiom currently only in AspectJ programs, but I expect, that this antiidiom will also appear often in other AOP languages as soon as they mature and gain a wider audience. Applications of the PROCEED PATTERN are also described in literature. Two [8][9] of the currently published AspectJ books describe the applications build on this pattern. I observed all patterns in the wild from where I minded them. All these idioms and patterns have been extracted from commercial AspectJ projects in which I was involved. AspectJ did have a great influence on my choice for the names of the participants and the patterns. However I do not consider it as a drawback, for the following reasons: • Most current AOP adopters have at least a basic understanding of AspectJ and of its terms, • Quite a lot of AOP languages and Aspect Oriented Software Development (AOSD) tools reuse also the AspectJ terms. • Quite a lot of AOP papers use AspectJ-Terms. Even more, I consider the AspectJ based naming a plus in practical commercial projects. Most commercial AOP projects I am aware of are based on AspectJ. If new developers are added on this project, they have to learn the new language, its terms and its ideas. A pattern vocabulary quite close to the AspectJ language benefits from AspectJ learning and training and these patterns and their names teach new AspectJ adopters patterns and samples for easier adoption. As mentioned above a short introduction into the ideas and AspectJ terminology can be found in the Appendix to this paper to offer an easy transfer of these pattern to other AOP platforms and languages.